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Abstract 

The Integrated Test Facility (ITF), being built at 
NASA Ames-Dry den Flight Research Facility, will pro- 
vide new test capabilities for emerging research air- 
craft. An overview of the ITF and the challenges being 
addressed by this unique facility are outlined in this 
paper. The current ITF capabilities, being developed 
with the X-29 Forward Swept Wing Program, are dis- 
cussed along with future ITF activities. 

Nomenclature 


CAD 

computer aided design 

FCC 

flight control computers 

ITF 

integrated test facility 

KASDT 

knowledge aided system design tool 

LVDT 

linear variable differential transformer 

PCM 

pulse code modulation 

psi 

pounds per square inch 

RAV 

remotely augmented vehicles 

RCD 

remotely computed displays 

RCV 

remotely computed vehicles 

RPRV 

remotely piloted research vehicles 

SID 

simulation interface device 

STIL 

system test interface language 

STR 

system test report 


Introduction 

The goal of the Integrated Test Facility (ITF) is to 
provide ground test capabilities that allow safe and 
efficient testing of advanced, integrated research air- 
craft. Characterized by the integration of flight con- 
trol, propulsion, structures, and aerodynamics, these 
integrated research aircraft rely on embedded digital 
control systems. The ITF addresses the qualification 
needs of today’s integrated systems aircraft. 1 


*ITF Lead Engineer 
I Senior Simulation Engineer 
* Lead Simulation Engineer 
$ Lead Electromechanical Engineer 


The ITF will reduce flight test risk by minimizing 
the difference between the flight and ground test en- 
vironments. This ground test environment is provided 
by interfacing the real-time flight simulation with the 
actual aircraft through a simulation interface device. 
Other challenges being addressed by the ITF include 
increasing test efficiency by automating the test pro- 
cess; the collection and management of test data; and 
information management of the aircraft systems and 
ground-based simulations (the management of infor- 
mation describing complex, interrelated systems). 

An overview of the features of the ITF building, the 
challenges facing the facility, and the progress made to 
date in addressing these challenges are provided in this 
paper. Future development activities for the ITF also 
are summarized. 

Overview of the 
Integrated Test Facility 

In the first section of this paper, we give an overview 
of the physical features of the ITF building and de- 
scribe the major functions provided by the ITF. The 
three major functions addressed are aircraft simula- 
tion, the remotely computed vehicle system, and air- 
craft maintenance. These functions are currently per- 
formed at Ames-Dryden, but their capabilities will be 
enhanced when they are moved into the ITF. 

Building Features 

A cutaway view of the ITF is shown in Fig. 1. The 
facility contains hangar (test bay) space for six fighter- 
size aircraft, broken into three separate areas. Each 
area can be configured to support classified projects. 
The aircraft technicians and maintenance staff are on 
the first floor of the central section. The engineering 
staff is in the front section of the building, with am- 
ple room allowed for visiting contractors. The second 
floor of the center section of the building houses the 
flight simulation systems, placing them in proximity to 
all six test bays. This allows the required short con- 
nection distances between the aircraft and simulation 
systems needed for closed-loop simulation with the 
flight vehicle. 
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Aircraft services, such as electrical power, hydraulic 
supplies, and cooling air, are provided to support 
aircraft-in-the-loop simulations. All the aircraft ser- 
vices can be monitored in real time when performing 
tests with the aircraft (Fig. 2). 

The electrical power provided includes 277/480 V 
and 120/208 V, three phase, 60-Hz power; 120/208 V, 
three phase, 400-Hz power; and 28 V dc power. 

The hydraulics systems for the six test bays are inde- 
pendent, allowing for different pressures and fluids to 
be used. The initial hydraulics system is a three-pump 
system providing 35 gallons per minute (gal/min) at 
5000 pounds per square inch (psi) pressure for each of 
the three pumps. This provides a total of 105 gal/min 
at 5000 psi. The flow per pump can be increased to 
50 gal/min at a pressure of 3500 psi. 

The aircraft cooling system is designed to provide 
each test bay with 4000 cubic feet per minute (ft 3 / min) 
of air flow. Exit air temperature is 40°F, provided 
through two 14-inch supply ducts. 

Aircraft Simulation 

The ITF will support flight simulation systems at 
NASA Ames-Dry den. The simulation systems will 
bring to the ITF 30 years of real time simulation expe- 
rience and expertise. Simulations are important engi- 
neering tools used through all phases of flight research. 
The simulations are used to perform various tests: time 
history, frequency response, redundancy management, 
failure modes and effects testing, and pilot evaluation. 

To augment these diverse uses, the ITF will sup- 
port multiple simulation configurations for a given 
project with varying levels of aircraft hardware in- 
cluded. These simulations run the full spectrum from 
simple batch versions, which use only the computer 
and a user terminal, to complex aircraft-in-the-loop 
versions. This allows the project team to easily se- 
lect the level of hardware needed to support a session’s 
activities. This flexibility permits quick comparisons 
between software models and flight hardware. It also 
allows a proposed modification to be tested in the ITF 
before being installed on the aircraft. 

High-fidelity modeling of the aircraft systems and en- 
vironment is of key importance in the ITF. This high- 
fidelity modeling provides aircraft hardware with a re- 
alistic flight environment. This task becomes increas- 
ingly important and demanding as aircraft systems be- 
come interdependent. 

A major goal of the ITF is to provide a flexible, ca- 
pable, engineering environment responsive to the user’s 
needs. The ITF simulation interfaces give users finger- 
tip control of the simulation. The simulations can be 
controlled by buttons and switches in the cockpit, or 
from a menu of display pages on a cathode ray tube 
(CRT), or the entire control mechanism can be run 


automatically from the workstation. The workstations 
generate simulation script files to automate the process 
of running tests. They provide a high-level simulation 
interface, bypassing the need to know the simulation 
commands to enter at the CRT display page. 

Remotely Computed Vehicles 

The ITF will have the ability to operate remotely 
computed vehicles (RCVs). As with the simulation sys- 
tems, Ames-Dryden has a great deal of experience with 
RCV systems which will be transferred to the ITF. 

RCVs will use telemetry uplink and downlink sys- 
tems and ground-based computers in the ITF. The 
ground-based computers are named the Control Law 
computer and the Pulse Code Modulation (PCM) com- 
puter. The Control Law computer is FORTRAN pro- 
grammable and is used to augment the onboard con- 
trol systems. The Control Law computer uses down- 
link data to generate aircraft commands. The PCM 
computer shares memory with the Control Law com- 
puter and is the interface between it and the telemetry 
stream. The PCM computer converts between scaled 
integers used in the telemetry stream and engineering 
units used by the Control Law computer. 

Currently, a computer identical to the Control Law 
computer is paired with each simulation computer for 
verification and validation of the RCV ground-based 
software. The simulations are designed to interface to 
this computer in the same maneuver as the PCM com- 
puter. Timing relationships are preserved to accurately 
model the real system. The relationship between the 
Control Law computer and the PCM computer in the 
RCV laboratory and in the simulation lab is shown in 
Fig. 3. 

The three types of RCVs supported by the ITF are 
described as follows and shown in Fig. 4. 

1. Remotely piloted research vehicles (RPRVs) are 
flown from a ground-based cockpit. The vehicle’s con- 
trol laws are coded in FORTRAN and executed in 
the Control Law computer. RPRVs that have been 
flown at Ames-Dryden range from the subscale highly 
manueverable aircraft technology (HiMAT) vehicle 2 to 
the joint FAA/NASA Controlled Impact Demonstra- 
tion using a Boeing 720. 3 

2. Remotely augmented vehicles (RAVs) use the 
ground computer to augment the onboard control 
system. This ability can be used to test alternate con- 
trol laws, insert sophisticated autopilots to fly precise 
research maneuvers, or to generate pulses or frequency 
sweeps for data analysis. The X-29 airplane is an exam- 
ple of a current research aircraft using RAV operation. 

3. Remotely computed displays (RCDs) help to 
guide the pilot in flying a precise manuever. The 
Control Law computer uses downlinked data to cal- 
culate the fly-to signals sent to the aircraft display in- 
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struments. An example of a current research project 
using RCD operation is the F-18 aircraft high angle- 
of-attack project. 

Once the RCV laboratory is moved to the ITF, its 
design will be improved by removing the need for the 
duplicate Control Law computer. In the ITF, one Con- 
trol Law computer will interface to both the simulation 
and PCM computers. The same computer will be used 
to test and execute the control law code. This will elim- 
inate the overhead associated with strict configuration 
control between duplicate computers. 

Aircraft Maintenance Facilities 

Routine aircraft maintenance required by the flight 
research vehicle is also provided within the ITF. This 
includes the preflight and postflight checks of instru- 
mentation systems and the servicing of hydraulics 
systems. The first floor of the central section pro- 
vides shop space for the instrumentation, avionics, 
and mechanical system technicians. Space is pro- 
vided for nongovernment technicians working on flight 
test programs. 

Challenges Facing the ITF 

In this section, we address the challenges facing de- 
velopment of the ITF and the steps being taken to 
meet these challenges. The approach is to develop the 
capabilities while the building is being constructed in 
order to provide a functional facility when construction 
is completed in early 1990. Current research vehicles 
such as the X-29 forward swept wing aircraft are being 
used to demonstrate these capabilities. 

Routine Setup of Aircraft-in-the-Loop 
Flight Simulation 

A primary function of the ITF is to facilitate the 
development and test of research aircraft using 
aircraft-in-the-loop simulations. Such simulations have 
been constructed at Ames-Dry den, with HiMAT be- 
ing an example. These simulations have required a 
great deal of time and effort to build and were very 
project specific. 

For the ITF to be successful, development of aircraft- 
in-the-loop simulations will need to take place quickly 
and efficiently. Once the development effort is com- 
plete, the simulation system will need to be easily con- 
nected and disconnected from the aircraft being tested. 
Because Ames-Dryden flies many unique research vehi- 
cles, this interface will need to be flexible. The interface 
will have to support vehicles that range from commer- 
cial planes like the Boeing 720 aircraft to fighters like 
the F-18 aircraft. 

The general requirements for interfacing between the 
simulation and the aircraft systems are described in the 
following paragraphs. 


The first requirement is a real time analog interface 
to the aircraft flight control, avionics, sensors, and ac- 
tuators. This interface is necessary to provide the air- 
craft systems with an environment that is as realistic 
of flight as possible and to allow the simulation sys- 
tems to monitor the aircraft systems being tested. 

The second requirement is protection of the aircraft 
electronic systems from electrical overloads. The same 
aircraft that are actively flying research missions will be 
used for ground testing in the ITF. Thus care must be 
taken to prevent possible damage to aircraft systems. 

The third requirement of the interface is the capa- 
bility to interact with the aircraft systems without in- 
ducing undesired side effects such as large ground loop 
currents. The interface must not induce time delays 
or other effects that will alter the dynamics of the air- 
craft’s response. 

The fourth requirement is the ability to support re- 
mote, electronic configuration of the interface. This re- 
quirement is generated by the need to use automated 
testing. In order to automate the testing process, the 
simulation computer will need to control the setup of 
gains and biases for the interface. 

The challenge of providing a flexible analog inter- 
face between the simulation computers and the re- 
search aircraft is being met by the simulation interface 
device (SID). A SID prototype is under development 
to demonstrate the general requirements outlined in 
the foregoing paragraphs. The first application of the 
SID is an aircraft-in-the-loop simulation with the 
X-29 aircraft. The X-29 application imposes project 
specific requirements upon the SID which will also 
be demonstrated. 

The specific requirements of the X-29 aircraft for the 
SID include (1) real time six degree of freedom simu- 
lation with the actual flight aircraft, (2) summation 
of the aircraft’s sensor outputs with the values coming 
from the simulation, and (3) the ability to dynamically 
change gains in the SID paths to validate flight control 
gain margins. The test configuration with the X-29 
aircraft and the relationship of the SID to the other 
systems are shown in Fig. 2. 

The generic SID provides unique real time analog 
and discrete aircraft interfaces by means of electronic 
card slots containing aircraft specific circuitry. Each 
SID rack provides 128 analog and 16 discrete card slots. 
The design of each card may be generic in some cases. 
In other cases, it is unique to the aircraft systems which 
must be connected. In the case of the X-29 aircraft, the 
SID includes cards that sum aircraft sensor values with 
values from the simulation (Fig. 5), cards to substi- 
tute values for attitude sensors using synchro outputs, 
and cards to demodulate the linear variable differen- 
tial transformer (LVDT) outputs of the actuators into 
direct current (dc) voltages. 
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The summation of the aircraft sensors to the simu- 
lation’s values allows the flight control system to de- 
tect the aerodynamic response of the aircraft and the 
structual response of the aircraft as measured by the 
onboard sensors. This is essential for performing struc- 
tural resonance tests in which the aircraft’s sensor val- 
ues are multiplied by a gain until a structural resonance 
is detected. The gain determines the amount of margin 
available for the control loop. 

Each of the card slots can be programmed with up to 
eight specific values to support automated testing. In 
the case of the card that sums aircraft values with sim- 
ulation values, the card can be remotely configured to 
change the gain in either path, to directly connect the 
aircraft sensors to the vehicle without summing in the 
simulation values, and to adjust output signal biases. 

Overvoltage protection must be designed to match 
the type of signal which is received or sent to the 
aircraft. As a result, the overvoltage protection is a 
generic feature of the SID but is designed to the spe- 
cific requirements of each research aircraft. Each of the 
three types of cards for the X-29 aircraft, the summa- 
tion card, the synchro card, and the LVDT card, has 
its unique overvoltage protection circuitry. 

Because significant ground potential differences ex- 
ist between the simulation computer and the aircraft 
(which is electrically connected to a supporting hy- 
draulic system, a power source, and other services), it 
is frequently difficult to accurately transfer low- voltage 
signals back and forth. The SID addresses this prob- 
lem by providing only nonohmic connections to the air- 
craft. Depending on the signal type, these connections 
use dc isolation amplifiers, transformers, and relays as 
appropriate. These isolation devices are included on 
each card. 

The simulation interface device provides the flexibil- 
ity needed to quickly connect the flight simulation sys- 
tems to the variety of research aircraft flown at Ames- 
Dry den. It does so while providing real time inter- 
faces needed for flight simulation, protecting the air- 
craft electronics, and supporting remote setup and test 
automation. The SID is an essential part of the ITF, 
providing the aircraft electronics with a test environ- 
ment surpassed only by actual flight. 

Increasing Ground Test Efficiency 

There are two main areas of ground testing that re- 
quire increased efficiency. First is the ground testing 
to verify system and software changes made to the 
research vehicle. These changes typically occur on a 
monthly basis and require large amounts of testing. 
Second is the ground testing performed between flight 
test sorties. This addresses preflight and postflight 
checks of instrumentation, and ground test of the spe- 
cific research experiment being flown. This testing is 
short in duration but occurs frequently, usually daily. 


Software and system verification is the first area to 
be addressed in the ITF because of the high costs and 
time to complete this test. The flight critical nature 
of the software, usually flight control software, also re- 
quires that steps be taken to improve the process of 
ground testing in this area in order to minimize flight 
test risk. Protection against test conductor errors and 
the ability to reproduce test setup conditions need to 
be improved. The rate at which tests can be started 
and carried out will have to be greatly increased be- 
cause of the volume of tests required in today’s highly 
integrated aircraft. 

The number of flight control software changes that 
occur on a typical flight program runs into the hun- 
dreds. The advanced fighter technology integrated 
(AFTI) F-16 program processed 240 change requests 
during the digital flight control system flight test phase, 
the majority being software changes. 4 Development of 
the A3 10 slat and flap control system saw over 700 
software change requests. 5 Testing must address each 
change individually as well as verify that functions 
which were not changed still work correctly. 

The challenge is to increase ground test efficiency 
by automating the test process used in the verifica- 
tion and validation of flight critical software systems. 
The X-29 project was selected to demonstrate the first 
phase of the automated testing process designed to 
meet this challenge. 

The X-29 test chosen for demonstration was an open- 
loop frequency response. This test was selected because 
it is an actual application, being part of the verification 
and validation process of new blocks of flight control 
software and requires nearly 50 test runs. The test was 
performed on the real time hardware-in-the-loop simu- 
lation. This simulation contains flight control comput- 
ers (FCCs) identical to those in the airplane. 

An engineering workstation was added to the simu- 
lation system to facilitate the automated test (Fig. 2). 
Public domain software and commercially available 
hardware and software packages were used in the work- 
station system wherever practical. The workstation 
provided several capabilities summarized in the follow- 
ing paragraphs. 

One of the key elements of the automated test sys- 
tem is the data base management system it provides. 
The data base management system provides a user in- 
terface for inputting test data and a method for ex- 
tracting data to set up the initial conditions of the test 
run. It also archives the test results data files. These 
initial conditions and results files can be accessed by 
the system for comparing data and producing reports. 
The management system can query the data base and 
list test results that meet stated criteria. 

A communication link between the simulation sys- 
tem and the workstation was also an essential capa- 
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bility that was added. The current link uses pub- 
lic domain software and an RS-232 connection. This 
link will be replaced by one with a higher data 
transmission rate. Ethernet (Xerox Corp., Stam- 
ford, Connecticut) and MIL-STD-1553 are two busses 
being considered. 

Another capability of the automated test system is 
the data analysis tools it provides. These tools are used 
to analyze the data collected from the test. For the 
X-29 automated test demonstration, a public domain 
data analysis software package was selected to generate 
phase, gain, and coherence data from the input and 
output data recorded during the open-loop frequency 
response test. 

A final capability of the automated test system is 
the ability to make graphs and reports for evaluation 
and documentation of the test. The data produced by 
the data analysis tool are presented to the test conduc- 
tor on a graphic monitor and also output on the laser 
printer. The report generation capability of the work- 
station outputs system test report (STR) forms. Seg- 
ments of these forms are automatically filled in from 
data extracted from the data base. Written descrip- 
tions of the test are filled in by the test conductor. 

The X-29 simulation software required modification 
to support the automatic testing. These modifications 
were made in a generic manner for easy incorporation 
into other simulations. The automated testing simu- 
lation software was designed to be flexible enough to 
handle all anticipated flight control system tests. 

Figure 6 shows the flow of control and data through 
the automated testing system used for the X-29 demon- 
stration. The test conductor starts the process by se- 
lecting a test from the data base menu. The data base 
management handler then executes the system test 
interface language (STIL) interpreter. This program 
extracts the information needed for the selected test 
from the data base and generates a script file of simu- 
lation commands. 

The resulting script file is then automatically trans- 
ferred to the simulation computer and the simula- 
tion is executed. The simulation follows the script of 
commands, setting up the initial conditions of the test, 
and then performs the test while collecting and stor- 
ing the real time data. During the test, the simulation 
sends a display to the workstation which can be mon- 
itored by the test conductor. The simulation is then 
stopped, and the test results are automatically sent to 
the workstation. 

Once the data are retrieved by the workstation, the 
data analysis program is started. The data analysis 
program runs from script commands and outputs the 
plots to the test conductor's display terminal and a 
laser printer. The STR documentation is then gener- 
ated and printed. The results of the test are archived 


on the workstation and can be retrieved for comparison 
against future tests. 

This approach to automate the frequency sweep test 
on the X-29 aircraft was successfully demonstrated. El- 
ements derived from this automated testing demonstra- 
tion are now being applied to other tests to increase the 
efficiency of validating new blocks of software for the 
X-29 airplane. With the inclusion of a high-speed data 
path between the simulation and workstation, open- 
loop frequency response tests can be run at a rate of 
up to 15 per hr. This includes all aspects of the test 
process, such as setup, frequency sweep, data record- 
ing, data analysis, and final documentation. 

Data Collection and Management 

The collection and management of large amounts of 
test data is another challenge facing the ITF. A difficult 
problem occurs in testing complex interrelated aircraft 
systems when a nonrepeatable failure happens. Often 
the data needed to resolve the failure is missing, but 
rerunning the test, with the proper instrumentation, 
does not reproduce the failure. By recording all pos- 
sible aircraft and simulation data during a run, the 
ability to resolve a failure without repeat runs is more 
likely. The ITF systems will need to collect and record, 
in real time, data from the simulation, the aircraft dig- 
ital data busses, the telemetry system, and the ITF 
services (hydraulic pressure, cooling air temperature). 
An estimate of the quantity of data to be recorded is 
shown in table 1. These data will need to be time 
tagged to enable time correlation of events that occur 
during the test. 


TABLE 1.— DATA SOURCE AND QUANTITY 
FOR RECORDING 


Source 

Number of 
parameters 

Rate, Hz 

Total, 

sample/sec 

Simulation 

Aircraft 

50 

100 

5,000 

Flight control 

300 

100 

30,000 

Digital busses 

— 

— 

150,000 

Telemetry 

100 

100 

10,000 

ITF services 

20 

10 

200 


Total 195,200 


The method of collecting and storing the large 
amounts of data needed for air craft-in- the- loop test- 
ing has yet to be determined. Some of the possibilities 
include (1) high-speed disk drives, (2) large banks of 
memory that can be dumped to disk after the run, (3) 
use of data compression schemes, and (4) a dedicated 
input-output computer with shared memory to the 
simulation system. The actual solution will likely be a 
combination of these approaches. The goal is to record 
all aircraft and simulation data during a test run. 
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A method of managing the test data will be required. 
The ITF will have data bases for each flight program 
(Fig. 7). Each data base will contain data from flight 
test and simulation runs which use varying amounts 
of hard ware-in- the-loop. The management system will 
need to track the revision levels of the simulations and 
flight software used in each test run. Revision levels 
will change with hardware and software modifications. 
For each data set from a given simulation, many dif- 
ferent kinds of tests will be run. For each run, the 
system will need to track the flight conditions under 
which each test was performed. 

A data base management system will be used to 
track the data sets. This data base management sys- 
tem will track all of the key parameters mentioned. 
This system is expected to be an outgrowth of the man- 
agement system currently in use with the automated 
test system. The data base management system pro- 
vides test personnel with the ability to find and com- 
pare test runs within minutes. Since the majority of 
testing is the reverification of a baseline system, com- 
parisons to previous test data are essential. 

Extensive real time data recording of all possible 
aircraft and simulation data, coupled with the data 
base management of simulation and flight test data will 
greatly increase test efficiency and help to ensure air- 
craft flight safety. 

Aircraft and Simulation System 
Information Management 

The increased complexity of research aircraft has 
caused an overflow of information to flight test person- 
nel, which can no longer be managed by manual tech- 
niques. Avionics systems functionality, hardware and 
software descriptions, and system reliability cannot be 
tracked and properly assessed using written documen- 
tation. Knowledge held by the design team is often 
lost by the time flight testing begins. Test conductors 
are often left examining piles of documentation in an 
attempt to determine proper system operation. This 
problem is not limited to research aircraft, but is also 
a major concern for the space station. 6 

For example, an error is likely to pass undetected 
when the independent test team, meaning independent 
of the design team, must become knowledgeable about 
a design by reading stacks of written documentation. 
This is a time-consuming effort with little chance to in- 
teract with the designer. What is needed to create good 
test plans is easy access to knowledge about the design. 

The problem of understanding and documenting the 
flight research systems is compounded when it must be 
tied to a ground simulation system for testing. Flight 
critical control system validation is one example that 
requires this type of configuration (Fig. 2). Often when 
something is not working, the question is asked, “Is it 
the simulation or the control system?” Managing the 


aircraft and simulation information, that is, the func- 
tional, system, hardware, and software descriptions, is 
essential for accurate and timely testing. 

The challenge is to provide a computerized method 
of documenting complex research systems, showing all 
the interactions that can take place. This challenge is 
being met by the use of the knowledge aided system de- 
sign tool (KASDT). The tool is being developed first to 
address the computerized management of information 
on a research flight control system. This information 
is typically multidisciplinary data and covers a range 
of aircraft systems. Once the tool is developed to doc- 
ument the more complex and critical aircraft control 
system, it can then be expanded to include the simu- 
lation system data. 

The KASDT is using the latest techniques from ar- 
tificial intelligence and expert systems to provide a hi- 
erarchical knowledge base and a set of reasoning func- 
tions that describe a flight control system (Fig. 8). 
The knowledge base consists of three main sections: (1) 
system descriptions, (2) software descriptions, and (3) 
hardware descriptions (Fig. 9). Reasoning functions 
are provided to help the user examine the knowledge 
base and perform high-level analysis of the system. 

The approach used to describe the three sections 
of the knowledge base varies for each section. The 
system description contains a functional description 
of the flight control system using structure design 
methodologies. 7 The top-level design for a flight con- 
trol system is shown in Fig. 10. Circles represent 
processes, boxes represent external devices (typically 
hardware), and lines represent data flows. The top por- 
tion of the figure shows the knowledge base graph for 
the processes described. This technique has been pop- 
ular in the software engineering community. The user 
graphically builds the system design on the screen while 
the tool automatically builds the underlying knowledge 
base. The system knowledge base is linked to the ap- 
propriate sections of the hardware and software knowl- 
edge bases which describe the actual implementation 
of a function. 

The method used to describe the flight control soft- 
ware is essentially the same as that used for the 
system description. Structured design techniques are 
used as before, but the knowledge base created is ap- 
propriate for software information. Links to a separate 
software development system are provided to download 
the software descriptions without retyping the data. 
The knowledge base is designed specifically to describe 
Ada software. 

The method for describing the hardware is different 
from the others because of the variety of hardware de- 
vices. Descriptions of aircraft sensors, computers, ac- 
tuators, pilot displays, and communication devices all 
require unique descriptions. The aircraft electrical and 



hydraulic systems must also be described. Therefore, 
the approach is to create a library of such devices that 
can be graphically connected into a system. This is the 
same technique used by computer aided design (CAD) 
systems to design electronic circuit boards. 

Reasoning functions provide the users with ways 
to view and analyze the information. One example 
of a reasoning function from the software area is 
the ability to set initial conditions, such as flight con- 
trol mode and gear position, and have the system deter- 
mine which software paths are active and the amount 
of real time being used. This information is then dis- 
played in graphical format showing data flows, pro- 
cesses, and timing. 

Once the generic user interface and knowledge base 
design are completed, the flight control system infor- 
mation can be added. The tool is designed to support 
the descriptions of any complex digital system, allow- 
ing expansion of the information to include the ground- 
based simulation system. 

By providing complete system information in graph- 
ical format, with supporting reasoning functions, test 
engineers will gain the insight required to effectively 
qualify today’s research aircraft. 

Concluding Remarks 

The Integrated Test Facility, with its new capabili- 
ties, will provide a ground test facility unlike any other. 
By being able to routinely interface the research air- 
craft with the flight simulation, the risk of flight re- 


search will be minimized. Automated testing is in- 
creasing test efficiency, allowing more productive flight 
testing. The ITF brings to the flight research commu- 
nity capabilities needed to ensure our preeminence in 
aeronautics and provide safe, efficient flight testing. 
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Fig. 2 Overview of ITF test systems. 
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Fig . 3 Control law system configurations for 

flight and development. 



(a) Remotely piloted vehicles. 



Fig. 4 The 


(b) Remotely augmented vehicles, 
three remotely computed vehicle configurations. 
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(c) Remotely computed displays . 
Fig . 4 Concluded . 
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Fig. 6 Automated test system . 
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Fig. 7 Five levels of data base detail. 
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Fig . 8 Structure of tool. 
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Fig. 0 System knowledge base. 
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The graph of the process objects unit in the system -design knowledge base 
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Fig. 10 Top level flight control system diagram . 
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